1. Field of Invention
The present invention relates to processes and systems for using a graphical entry to generate or select search terms and perform a query of a data store, and graphical manipulation of results of the query to perform edits to information stored in the data store. More particularly, the invention relates to such processes and systems wherein the data store contains configuration management data which is queried and edited.
2. Discussion of Related Art
Developing software applications and products (which includes both initial development and later modifying or adding to the initial development) often requires the coordinated efforts of many developers (e.g., software programmers). This coordinated effort is referred to herein as a “software development effort” or “development effort,” and a body of work (e.g., one or more software products, including software applications) being developed by the effort is referred to as a “software development project,” “software project,” or “project.” A software development effort may comprise one or more software projects. At any given time, as part of a software development effort, multiple developers may be working on different software components of a software development project and/or different versions of these software components (e.g., for different customers or situations). Thus, there may be multiple concurrent software development efforts ongoing, at least some of which use or involve the modification of common software components, including different versions of those software components and sometimes multiple versions of components. Frequently, a software development project may involve several, or even dozens or more, of developers and managers, and from a few to even hundreds of software components. Managing one or more software development projects and the concurrent development of these different software components and versions is commonly referred to as configuration management (CM). Computers or computer systems running CM software applications (i.e., programs) assist developers and project managers in the complex task of managing a software development project. (Hereafter, the term “CM application” may be used to refer to such computers or computer systems, or to a CM program for executing on a computer or computer system.)
A software development effort most often involves adding or improving functionality (i.e., adding features) to a product, and fixing functionality that is not working properly (i.e., fixing defects or “bugs”). Sometimes, a software development effort may involve removing functionality from a product, such as when a customer desires a simplified version of the product. Typically, one or more fixes, feature changes (whether additions, deletions, or a combination), or combinations thereof (each a development “item”) are grouped together as a development unit called an “issue.” At a minimum, an issue is defined by one or more development items, and often includes other information, such as information which may be used to identify a developer working on the issue and/or a software project with which the issue is associated (i.e., a “Target Release” for the issue). The statuses of issues are often tracked as part of a development effort (often with CM software), as an aid to management of the development process; accordingly, tracking information may be added to an issue description. Upon completion, the tracking information (i.e., tracked statuses) may indicate that the issue has been resolved or finished.
A software development effort may comprise any number of issues, with a software project of the software development effort comprising a single issue—in which case the software project may be considered to be the issue—or comprising multiple issues.
Because of the often significant numbers of issues involved in a development effort (which may number in the dozens, hundreds, or thousands), efficient management of development efforts typically relies on use of an issue tracking system to track the progress of the resolution of each issue. Often, tracking systems are implemented using a computer system, for example, as part of a CM application. Such computerized tracking systems may provide a unique identifier (e.g., a serial number) for each issue, and provide data fields that enable a user (e.g., a developer, supervisor, or project team leader) to track the progress of the issue's resolution by indicating status changes and the like (e.g., when the issue is assigned to a particular developer to be completed, when it is sent to the quality assurance (QA) team for testing, or when it is declared tested and complete, etc.), from time to time, and to identify who is responsible for addressing each issue.
As described above, a software development effort, or concurrent efforts, often involves multiple developers working concurrently on different versions of the same and different software components for the same or different software projects. Some CM applications provide each developer a “workspace” (defined below) in which the developer can add, modify, and delete components of a software project pertinent to the developer's objective (e.g., completion of an issue). Further, a CM application may maintain one or more versions of the project itself (e.g., branches or streams—defined below), and a developer's workspace may be configured to enable the developer to make changes to a particular version of the project. As used herein, a “version” of a software development project (or other software entity) is a set of software components of the project, and for each software component, a version (i.e., instantiation as of a specific date and time) thereof. It should be appreciated that different versions of a software project (or other type of software entity) may have much the same content (e.g., may include much the same set of software component versions) or quite different content. A developer's workspace may be considered a version of the project or as containing a version of the project, at a given time.
It is often desirable to propagate modifications made in a developer's workspace (e.g., an addition, change or deletion of one or more software objects) to other versions of the project or to other projects, including other workspaces. CM applications often are configurable to provide such propagation. In CM applications having hierarchies of project versions and workspaces, propagation may comprise promotion of software components, in which software components are moved up in a hierarchy from a child version to a parent version, and/or updating of software components, in which software components are moved down in a hierarchy from a parent version to a child version.
In addition to providing the propagation of modified software components, some CM applications provide a tracking system that enables a user to record information related to software projects and/or issues managed by the CM application. For example, the information may comprise an indication that a particular issue resolution has been propagated to a particular version of the project. To determine that an issue resolution has been propagated to a version of the project, the user determines the software components and versions associated with the issue resolution, for example, by looking up the issue resolution in the issue tracking system. Then the user determines whether all of the versions of the software components have been propagated to the version of the project, for example, by looking up the list of software components and their associated versions currently in the project.
Related to issue tracking systems for software projects are workflow applications monitoring a workflow for one or more software projects. A workflow for a software project may be used to indicate or define a lifecycle for the software project, and may comprise a series of stages, related to one another by transitions, through which a software project may progress.
In many conventional implementations, developers of software projects manage workflows using a workflow application separate from any CM application and issue tracking system implemented by the developers. A workflow application may maintain (or be used to maintain) a record of a workflow implemented for a software development effort or software project, and may maintain records of the status of software projects or portions of software projects (e.g., individual issues) in the workflow. From these records, users (including managers of software development efforts) may be able to determine quickly the overall status of one or more software projects (e.g., the user may determine that a software project is completed if all the issues in the software project are completed). Such information facilitates predicting, among other things, software project timelines (e.g., when a software project will reach the “Closed”—i.e., finished—stage).
These records (i.e., issue tracking records and/or workflow records) may be queried by users (e.g., those editing software projects and/or those managing software projects) to determine properties of versions, issues, and/or software projects. Applicant has appreciated, however, that these available methods of searching conventional CM applications suffer from multiple disadvantages. Conventional CM applications provide users with the ability to query a data store of tracking information in several ways. For example, a conventional CM application may provide to a developer a command line into which the developer may type his/her search query. In these cases, the user may be required to know the structure of the data stored by the conventional CM application, such as the exact fields in a database in which desired data is stored. Such a system may be difficult to use, because due to the number of types of information managed by conventional CM applications, developers may not be able to remember the structure of data sufficiently to perform their queries. Further, information may be stored in fields with names that are confusing abbreviations or that are only loosely related to the information stored in the fields (e.g., an “issue number” may be identified with a field name such as “issnum,” “inum,” or “num,” rather than a clearer identifier such as “issueNumber”). As a result, if users do not know the names of the fields in the data store, the users may not be able to guess in which the desired data is stored. Thus, such an interface may make it difficult for the users to query effectively a data store.
As an alternative, some conventional CM applications provide a user with a search interface offering, for example, drop-down boxes populated with the names of the fields in which information is stored in the data store. From these drop-down boxes, a user may select the fields of the data store which they would like to query, and then specify values of these fields. Thus, users are not required to know the names of the fields in the data store, but may instead select them from the drop-down boxes. This approach overcomes the first disadvantage mentioned above (i.e., the developers in the above system had to memorize the field names) but still does not overcome the second; namely, that field names may be confusing or only loosely related to the data, and thus users may not be able to identify accurately the name of the field which they would like to query.
Further, being able to select certain search terms (e.g., field names) from an interface does not relieve a user from having to know how a data store is structured. For example, a user may desire a listing of all issues which have a certain state (e.g., all issues on which work is currently being done, or all issues which have been completed). However, the data store queried by the user may not store issue records with a concrete identifier of state or stage (i.e., issue records may not have a “status” field); instead, the status may be inferred from various conditions of the issue. For example, an issue may be considered to be in a “Scheduled” stage if it has been assigned to a particular developer, assigned to a target release of the software project with which it was related, and does not have any associated files or code (work has not yet begun on the issue), while if there is no developer assigned or target release, the issue may be considered to be in a “New” issue stage and if there are files or code assigned, then an issue may be considered to be in an “In Development” stage. A user of a CM application, seeking to query for status of issues, would need to know how the data is stored and (in this example) need to know the various conditions which have to be evaluated to determine status. Thus, even for concepts that may be simple to express, unfamiliarity with the structure of a data store may bar a user from performing certain status queries of a data store.
Conventional CM applications also suffer from the disadvantage that, whether users are able to select certain search terms (e.g., field names) or must specify search terms, all values must be specified using logical operators, and search terms must be related using the logical operators. Values for search terms may be specified as “the value is ——————” or “the value is less than ——————” or “the value is greater than ——————”. Search terms must be related with terms such as AND, OR, XOR (“exclusive or”), and others so that a search query may be appropriately executed by the system. For complicated queries, these search terms may also be grouped using parentheses. This allows the developer to specify terms which must all be satisfied, or which may be satisfied in the alternative. As an example, a user may enter a query such as, “(field1<10 AND field2==2) OR field3==5” (i.e., return all records which have both a value of field1 less than 10 and a value of field2 equal to 2, or record which have a value of field3 equal to 5). For users who are not familiar with the structuring of such logical statements, building such a query may be difficult or impossible, and thus the users may not be able to query the system for the information they desire.
Additionally, in conventional CM applications which do permit users to perform queries of the data store, where users are sufficiently familiar with the underlying structure of the data store and with logical operators to enter a search query, the conventional CM applications do not permit the users to interact with the results. A list of results of a search query in such conventional CM applications is a static listing which does not permit a user to manipulate the results directly on the result page and thereby automatically edit the underlying data. Instead, a user must open other windows and forms to perform edits to the data to alter the results, and may have to be familiar with the structure of the data to perform these edits (e.g., may have to know which fields of the data govern which change he or she wants to make in the results). Thus, even when a user is capable of performing a search in conventional CM applications, the user may not be capable of making interactive use of the search results.
Each of the above-discussed disadvantages (e.g., necessity of prior knowledge of data structure and search structure) seen in conventional CM applications is also seen in conventional workflow applications. A user looking for information on a software development effort, therefore, may not only have to overcome the disadvantages of the conventional CM application but may also have to overcome the disadvantages of the conventional workflow application, as information desired by the developer may be available in only one or the other. This highlights another disadvantage of conventional systems, which is that related information (e.g., issue tracking records and workflow records) is stored in distinct records by distinct applications and cannot be queried in a unified way. For example, a conventional CM application may store information relating to the files and versions of files with which an issue is associated, while workflow records may store information describing an issue's progress through the workflow (i.e., information related to the project timeline). Thus, a user may need to execute multiple different queries times in multiple applications to determine the information desired, tailoring each query to fit the data structure of the records of the application on which the query is being executed. Querying for information can therefore be an intense (and frustrating) process, and may lead a developer to fail to obtain desired information or to abandon the search because the search is prohibitively time-consuming and frustrating, or may lead the user to learn to execute only a certain set of queries and never attempt other queries which may provide other valuable information.
Accordingly, there is need of an improved search interface which allows users to specify easily and efficiently search terms, without needing to know the underlying structure of a data store. Further, there is need of an improved search interface which permits users to manipulate the underlying data of search results without performing complicated procedures involving additional windows and forms.